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[57] ABSTRACT 

The present invention involves a personal computer based 
system that emulates actions of a human technician correct- 
ing mainframe computer transactional records. The system 
performs analysis functions and update processing of main- 
frame transaction processing records transparent to the 
mainframe tiansaction application system. The automatic 
transaction processing system acts as a virtual terminal 
while supplying logic and control functions to sign onto the 
mainframe computer to access particular pre-selected main- 
frame / transaction records and traverse through the main- 
frame application correcting transactional records that have 
been flagged as errors. After correcting the errors on the 
mainframe computer, the system automatically logs off the 
mainframe computer. 
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AUTOMATED TRANSACTION PROCESSING 
SYSTEM AND PROCESS WITH EMULATION 
OF HUMAN ERROR RESOLUTION 

MICROFICHE APPENDIX 

This application includes a microfiche appendix having 
289 frames. A portion of the disclosure of this patent 
document contains material which is the subject to copyright 
protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent document or 
the patent disclosure, as it appears in the Patent and Trade- 
mark Office patent files or records, but otherwise reserves all 
copyright rights whatsoever. 

BACKGROUND OF THE INVENTION 

The present invention relates to a personal computer 
based system that emulates the actions a human being 
performs while working at a mainframe computer terminal 
to perform analysis functions and/or update processing on a 
mainframe transaction processing system. 

The prior work flow relationship between a human being 
and a mainframe computer during analysis and update 
processing of transactions is that data enters the mainframe 
system via electronic or manual key entry sub-systems and 
then a human technician conducts error trapping and cor- 
rection operations on the entered data. Normally, transac- 
tions are processed on the mainframe computer with a series 
of edit modules where transactions suspend due to erroneous 
data or for manual review edits due to data relationships that 
are inconsistent or in error. On these typical types of 
mainframe systems, for example such as those involved in 
medical claims processing, a pool of processing staff of 
between 8 to 10 people are dedicated to review these daily 
errors. The processing staff will log on to the mainframe 
using a "dumb" terminal and initiate portions of the main- 
frame transaction processing system to access claim or 
transaction data and perform error resolution processing. 
Error messages that are identified on the screen are caused 
to be corrected manually by the processing staff. Depending 
upon the error message received on the screen, the human 
technician will conduct recovery or integrity enhancing 
steps to correct the error on the mainframe data base. 

A prior art system for claim error correction processing 
utilizes hardware similar to that shown in FIG. 1. A main- 
frame computer 20 is attached by communication lines 22 to 
a "dumb** terminal 24 normally having a CRT display 26 
associated with it An operator 28 would interface and 
interact with terminal 24 to send communication signals via 
communication line 22 to mainframe computer 2#. Operator 
28 would manually edit and correct transactions that were 
flagged as errors by the transaction processing program on 
mainframe computer 20. Typical mainframe transaction 
application programs include such as Medicare A claims 
processing system from Blue Cross/Blue Shield of Arkansas 
and Medicare B claims processing system from V.LP.S. of 
Baltimore, Md although others may be used with small 
variations in the ATP setup procedure such as the Champion 
System from Admin aStar Defense of Columbus. Indiana, 
and D.M.E.R.C. Claims Processing System from VLP.S. of 
Baltimore. Md. As shown in FIG. 1, the mainframe com- 
puter 20, may be for example an IBM 3090 or Digital 117870 
VAX mainframe computer utilizing a central processing unit 
30 attached to associated processing circuitry 32 for 
recording, transmitting and manipulating data. CPU 30 
normally includes an associated input/output control unit 34 
for controlling data transmitted to areas external of main- 
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frame computer 20. An internal bus structure 36 permits 
signals to flow between CPU 30, I/O control 34. processing 
circuitry 32, and other storage apparatus of the computer 
such as RAM memory 38. disk storage 40 and associated 

3 tape storage media 42. The above described mainframe 
computer is conventional and known in the art. At some 
terminals 24. a printer 27 is attached for printing data and/or 
screen information. 
The prior human procedure for transaction error coirec- 

10 tion is shown in FIG. 3. A final deterministic conclusion by 
the system on the error code found, causes one of the 
following to happen, similar to the workflow accomplished 
by humans utilizing a terminal 24. Data on the mainframe 
transaction record may be updated to resolve an edit error 

15 and then the transaction continues on to finalization; or data 
on the mainframe transaction record is in error and cannot be 
updated so the transaction is denied or deleted; or data on the 
transaction is in error but further information is required. 
The transaction is put in a hold status and a request for 

2° additional information is sent to the transaction submitter. 
Transactions are processed on the main frame through a 
series of edit modules where transactions suspend due to 
erroneous data or for manual review edits, due to data 
relationships meeting selected criteria as is known in the art 
The transaction claim review process includes a human 
technician editing and examining the edit error or manually 
reviewing the situation and making a determination of the 
action to be taken. A final determination of the error and an 

M appropriate correction step causes one or more of the 
following to happen. Either the data on the transaction is 
updated to resolve the edit error and the transaction contin- 
ues on to final processing by the mainframe computer 
system or the data on the transaction is in error and cannot 
be updated so the transaction is denied or deleted. Another 
step may be that either the data on the transaction is in error 
but further information is required. The transaction is then 
placed in pending status and a request for additional infor- 
mation is sent to the original transaction claim submitter. 

40 As shown in the above description of error processing 
correction, a large amount of human labor is necessary for 
correcting erroneous transaction records on a mainframe 
computer. Additionally, the speed at which the mainframe 
transactions are corrected is dependent upon the capability 

45 of the person doing the correcting. Substantial problems 
with the system as presently utilized are that the accuracy 
and consistency of processing is variable since different 
people may conduct different error correction procedures for 
the same type of error. This type of variation in error 

50 processing may create non-uniform results even though 
technically correct Lastly, the repetitive nature of error 
detection and correction often results in an unsatisfying 
experience leading to a high degree of turnover in the human 
technician processing staff. 

55 SUMMARY OF THE INVENTION 

The present invention provides an automated transaction 
processing (ATP) system with a custom programmed pro- 
cess designed to work specifically with a mainframe-based 
60 transaction processing system. High-Level Language Appli- 
cation Programming Interface (HLLAPI) technology is used 
to perform and replace the human terminal interaction 
process while being transparent to the mainframe system, 
thereby requiring no modification to the mainframe appli- 
es cation program. The ATP system includes an intelligence 
process and utilizes HLLAPI function calls to directly 
interact with the mainframe system to perform tasks such as 



02/24/2004, EAST version: 1.4.1 



5.758,341 

error trapping and correction. The ATP procedure interacts the required error resolution processing by the local com- 

with the mainframe system in a number of ways. puter emulating a human operator interacting with the 

The present system performs the same type of mainframe transaction processing program 
terminal interactions as human technician performs includ- The invention comprises, in another form thereof, an 
ing the reading of data from the mainframe screen, posi- 5 apparatus for automated transaction review of transaction 
tioning the cursor at a point on the screen, writing data back data records used with a transaction processing program on 
to the terminal, and generating keystrokes (Enter, PF12, a mainframe computer including communication means for 
PAL etc.)* These actions are sequenced into a logical order communicating with the mainframe computer, means for 
to perform a specific task on the mainframe in the same initiating the transaction processing program of the main- 
fashion that a person would In this way, a personal com- 10 frame computer via the communication means and an error 
puter can do work that would ordinarily have to be done by resolution means for emulating a human operator interacting 
a human being. The advantages of automated transaction with the transaction processing program on the mainframe 
processing derives from the logical content and sequence of computer to correct errors in the transaction data records, 
how the actions are applied to mainframe transaction pro- The invention, in another form thereof, comprises a 
cessing systems to replace the human technician in the 15 method including the personal use of system having means 
workflow. for operating on a predetermined mainframe computer data 

Logging on the mainframe computer, initiating the main- base containing transaction error codes and data and a set of 

frame application, navigating the menus of the mainframe relationships among the transaction error codes and data 

application, and switching among multiple transactions as The method for processing transactions on the mainframe 

part of the work process all are provided in the preferred 20 computer, comprises the steps of logging on the mainframe 

form of the invention. computer and reading a transaction from the mainframe. The 

The ATP system also accesses data elements and data method men performs analysis functions on the transaction 

records from the mainframe system. These data elements on the mainframe processing system, then update processes 

can come from an unlimited number of screens or transac- toe transaction data on the mainframe processing system 

tioos. Afc* toe update processing is complete, the process logs off 

To mimic the operation of a human technician, the system mainfrarae com P uter ' 

analyzes the data present on the mainframe system using a The invention, in still another form thereof, provides a 

programmed set of procedures or logical analysis steps and computer system including a central processing unit and 

later performs actions required by the outcome of the logical 30 associated memory for emulating the action a human being 

analysis to validate or correct the data on the mainframe. performs while working on a mainframe computer terminal 

After correcting a first error, the system moves on to the to P**™ analysis functions on a mainframe transaction 
next transaction in sequence and again performs the logical Processing system The computer systeinincludes means for 
analysis and update activities. Whcn^U available work imtL ^ a mainframe application of the transacfron pro- 
tections aie^ompleted for all particular errors, the ATP 35 cessing system and means for accessing transaction data 
system will log off rf the mainframe system elements from the mai«Aame transaction pro^ssmg system 

' Means are also included for analyzing the transaction data 

An advantage of the ATP system of the present invention clemcnts u$in a preselected set of procedures while addi- 
is that of <x>st savings. The ^equivalent work of multiple ti ona i means are used for performing update functions on the 
human technicians can be performed by a single personal tnumctioo data element on the mainframe transaction pro- 
computer utilizing the logic and control feature and function 40 ^sine system. 

of the present invention. . A , ^ . 

r m . , , The invention, in yet another form thereof, provides a 

Another advantage of the ATP systeni is the automated TOmputa . systcm including a central processing unit and 

transaction processing procedures can perform the repetitive associatc 4 memory for emulating the actions a human being 

functions once performed by clerical staff. Personnel can be rforms whilc woridng « a mainframe computer terminal 

utilized to perform more meaningful work where human f Q ^ orm analysis functions on a mainframe insurance 

intelligence and analysis is required. claim transaction processing system The system includes 

Yet another advantage of the ATP system is the speed of means for initiating the mainframe application system and 

automated transaction processing is many times the capa- means for accessing data elements from the insurance claim 

bility of a human technician manually correcting errors on a x transaction records stored on the mainframe. A predeter- 

mainframe application data base. mined data base stored in associated memory contains 

Still another advantage of the ATP system is the pro- transaction processing error codes and procedures related to 

grammed procedure is performed the same way each time each error code for correcting data elements from the 

with no variation. The processing results are very uniform, insurance claim transaction records having a matching error 

resulting in higher quality, greater accuracy and consistency 55 code. Means are included for comparing the data elements 

of processing. to transaction processing error codes stored within the data 

A further advantage of the ATP system is maintenance base to find a matching error code and insurance claim 

time using the automated transaction processing source transaction record. A means for performing update functions 

language is comparatively short so procedure modifications is included in the invention so that update functions are 

can be incorporated on a very timely basis, 60 perfonned on the mainframe as required by the set of 

The invention comprises, in one form thereof, a process procedures related to the matched error code and insurance 
for automatic transaction review by a local computer of claim transaction record. 

transaction data records used with a transaction processing BRIEF DESCRIPTION OF THE DRAWINGS 
program on a mainframe computer comprising the steps of 

establishing a communication link between the mainfrarae 65 The above-mentioned and other features and advantages 

computer and the local computer, initiating the transaction of this invention, and the manner of attaining them will 

processing program by the local computer and performing become more apparent and the invention will be better 
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understood by reference to the following description of an 
embodiment of the invention taken in conjunction with the 
accompanying drawings, wherein: 

FIG. 1 is an illustration of the prior art hardware arrange- 
ment for correcting transactions on a mainframe computer; 

FIG. 2 is an illustration of the hardware arrangement used 
in correcting transactions on a mainframe computer in one 
form of the present invention; 

FIG. 3 is a prior art process flow chart of mainframe 
transaction error correction; 

FIG. 4 is a programming flow chart showing an overview 
of the operation of the automated transaction processing 
system of the present invention; 

FIG. 5 is a programming flow chart of the error processing 
parameter selection section of a preferred embodiment of the 
present invention; 

FIG. 6 is a programming flow chart of the error processing 
parameter selection section of a preferred embodiment of the 
present invention; 

FIG. 7 is a programming flow chart of the report file 
creation section of a preferred embodiment of the present 
invention; 

FIG. 8 is a programming flow chart of the start-up 
procedure section of a preferred embodiment of the present 
invention; 

FIG. 9 is a jtfograrnraing flow chart of the error resolution 
processing section of a preferred embodiment of the present 
invention; and 

FIG. 10 is a programming flow chart of the mainframe 
log-off procedure section of the preferred embodiment of the 
present invention. 

Corresponding reference characters indicate correspond- 
ing parts throughout the several views. The exemplification 
set out herein illustrates one preferred ernbodiment of the 
invention, in one form, and such exemplification is not to be 
construed as limiting the scope of the invention in any 
manner. 

DETAILED DESCRIPTION OF THE 
INVENTION 

There are several key principals upon which all ATP 
procedures are based that allow the system to interact with 
a main frame based application program. 

The first is that all actions have an expected outcome. 
Each action that causes a screen change within the main- 
frame system has a defined outcome. If the expected screen 
is not received or the expected action is not performed fully, 
the present invention is designed to stop or to react accord- 
ing to programmed instructions to deal with the variance 
from the desired outcome, such as stopping the transaction, 
calling an operator, or printing a report. In this way. the ATP 
system cannot perform actions that might corrupt data on the 
mainframe system, 

Additionally, a library of ATP functions has been defined 
as shown in the microfiche appendix. The source code of the 
ATP procedure is written to use the library of ATP functions. 
This makes coding easier and more uniform, A computer 
language. Visual Basic 3.0 available from Microsoft Inc. of 
Redmond, Wash, is utilized to translate the source code into 
a machine readable executable file. 

The ATP procedures are intelligent enough and flexible 
enough to handle variations in mainframe response and 
system performance. This flexibility is achieved through 
integration of defined 'wait' periods. If the mainframe 
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application exceeds the defined 'wait' parameter, the ATP 
system 50 can halt based on the lack of response or react 
according to programmed instructions to deal with the 
variance from the desired output from the mainframe com- 
5 puter. 

All ATP procedures generate audit trail files of the activity 
performed and are designed to include necessary security 
practices to allow traceback and crash recovery. 

The physical hardware of the ATP system is shown in 
FIG. 2 as a conventional personal computer 44 such as an 
IBM compatible personal computer 44 with 4 to 8 mega- 
bytes of ram memory, a hard drive and associated keyboard 
and communication line interface. As shown in FIG. 2. an 
optional printer 46 may be connected to personal computer 
44. 

With the process 50 (FIG. 4) of the present invention 
using personal computer 44. transactions stored on main- 
frame computer 20 may be edited quickly and efficiently in 
an automated fashion. 

Personal computer 44 of the present system is pro- 
grammed to access the edit error transactions on the main- 
frame via a standard communication connection. Personal 
computer 44 then accesses each of the error cases and 
performs a review of the data on the case and determines if 
any action is to be taken. The required action is then carried 
out on mainframe 44. The personal computer 44 can work 
through all the transactions it previously took a staff 6 to 8 
human clerks to handle each day. 

Upon initiation of the automated transaction processing 
(ATP) process 50. the following functions are performed as 
shown on first branch 52 of the flowchart of process 50 
depicted in FIG. 4: 
Entry of mainframe log-on parameters (58); 
Selection of error processing parameters (60); and 
Creation of a daily ATP report file (62). 
The ATP software for this application is started within a 
Microsoft Windows system environment The microfiche 
appendix of the application includes source codes for per- 
sonal computer 44 which was created for use on a Visual 
Basic 3.0 compiler running under a Microsoft Windows 3.1 
environment. Alternate code and system environments may 
also be utilized. Utilizing the executable code created by the 
appendixed source code, a screen is first presented to enter 
mainframe system 20 logon information 58. user ID and 
password information. The password field is blanked so the 
password Is not displayed, as is standard practice. Data files 
are also entered to identify the Clerk ID and Clerk password. 
A 'Done* command option button is selected after the 
required information is entered. The values are saved as 
string variables. After this, an initial form is presented with 
command burtons to either start the ATP system, stop a 
currently running ATP process, or enter the setup screen. 

The setup screen is automatically presented and the 
following information can be set in step set 60 as shown in 
more detail in FIG. 5. Check boxes in step 61 are included 
to individually select the error codes that will be worked on 
the transactions of mainframe 20. Drive/Directory selection 
in step 63 for report files are also set at this time. The ATP 
process fcf Wait Time" parameter used to handle timing or 
mainframe system response is also set to a value depending 
on the mainframe system utilized and associated application 
software. ATP system Shutdown Time (in step 65) is an 
automatic feature to shut off the processing at a prescribed 
time of day. When all setup options have been confirmed, the 
"Done" command button in step 67 is pressed. 

The second branch 54 of the system 50 flowchart of FIG. 
4 includes the ATP main processing system and performs the 
following functions: 
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ATP Start-Up Procedure — Sets all the functions necessary 
to set the ATP operation environment; 

Mainframe Log-On Procedure (66) — Performs steps nec- 
essary to log on to a specific mainframe computer 20 
and pre-identified transaction applications program s 
running on same. 

Error Resolution Processing (68) — This performs (he 
steps of navigating through the application system 
menus on mainframe 20 and performing the detail 
actions necessary to resolve a specific error situation; 10 
and 

Mainframe Log-Off Procedure (70)— That performs steps 
necessary to log-off mainframe computer 20 when all 
required processing has been completed. 

The actual sequence of command, characters, and/or other 13 
signals communicated from personal computer 44 to main- 
frame computer 20 is dependent on the type of mainframe 
computer, its operating system, and the type of program 
running on the mainframe. However, one of ordinary skill in 
the computer programming art can readily determine the 
necessary commands. 20 

The next sequential step is that of the ATP startup pro- 
cedure 64 as shown in more detail in FIG. 7 is to connect 
personal computer 44 to a virtual Presentation Space 13 on 
mainframe 20. The present software system initiates and 
executes the ATP library command Connect at step 73 which 25 
issues the HLLAPI function calls to connect with the 
designated terminal emulator window a designated Session 
A. Session B. etc. These session windows arc predefined for 
the type of terminal to emulate such as a VT 100, WYSE 50 
and other similar terminal types. The return code from the 30 
"Connect" function is then checked. If an unsatisfactory 
return code is found, processing branches to an error han- 
dling routine which report key statistics, displays error 
messages specific to this situation and then terminates the 
processing. 35 

The next action (FIG. 7) is to query the terminal session 
settings and validate mat the screen is configured in a 24 by 
$0 mode. This is accomplished by executing the ATP library 
command "Querysessionstatus" at step 75 which issues the 
HLLAPI function calls to return the value that defines the 40 
current virtual screen size. The values are interrogated and 
if they do not conform to the requirements, an error handling 
routine is called and the processing terminates. 

The ATP program then executes the "Startcloseintercepr 
ATP library command at step 77. This issues the HLLAPI 45 
function calls to turn on a monitor function that prevents the 
virtual mainframe session window from being closed while 
under the control of the ATP procedure and assures a 
determination and recoverable audit trail in the event of a 
system failure. so 

Upon successful completion of the "Connect" function, 
the ATP process checks to see that the mainframe banner 
screen from mainframe 20 is currently being displayed in the 
virtual presentation space at step 78 (FIG, 8). Alternatively, 
the mainframe banner screen may be displayed on the screen 55 
of personal computer 44. This is done by executing the ATP 
library command "Chkbanner" which issues HLLAPI func- 
tion calls to Search the presentation space (terminal 
window) for a specified character string that uniquely iden- 
tifies the transmitted screen as the banner screen. If this 60 
specified character string is not found within the time 
defined by the Wait Time parameter described above, pro- 
cessing branches to an error handler as the expected result 
has not been received. 

The presentation space is cleared by executing the ATP 63 
library command "Doclear" which issues the HLLAPI func- 
tion calls to perform a screen clear. 
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The next step of the mainframe log-on procedure 66 (FIG. 
8) is for the system to supply keystrokes at step 80 to access 
the production CICS system on mainframe 20. Keystroke 
signals are created and sent to the mainframe screen to 
perform a logon to the production CICS region. These 
keystrokes are contained in a string variable and arc sent to 
the mainframe using the ATP library command "Sendkey" 
which issues the HLLAPI function calls to send keystrokes 
to the screen. An example of this process is *CICSPT@E' 
(CICSFT is the name of a typical production CICS region — 
@E causes the equivalent of hitting the enter key to be 
performed). Processing is initiated and the mainframe 
responds to the keystrokes that have been sent. A 4f Waif 
command is issued to give the mainframe time to respond to 
the command and when completed the CICS unlocks the 
keyboard. This is the signal for the HLLAPI command to 
issue a positive return code indicating that the mainframe 
has responded and the program system of the present 
invention is clear to move on. 

The "Wait" command is issued as part of each library 
command that causes a mainframe action to occur. The 
return code is checked to see that mainframe 20 has 
responded. If mainframe 20 does not respond within the time 
frame defined by the "Waif time parameter (from the setup 
screen above) processing is passed to an error handling 
routine where processing will be terminated due to not 
receiving the expected result from mainframe 20 within the 
allotted time. 

A verify logon screen is then displayed and personal 
computer 44 enters the User ID and password. After issuing 
the initial logon, the ID/Password screen is expected. The 
program executes the ATP library command "Oikpswd" at 
step 82 which searches the presentation space for the key- 
word that indicate the password screen has been presented. 

Upon verification of the password screen, the logon 
information entered earlier is entered to the screen. This is 
performed by first identifying the screen position of the data 
field and moving the cursor to that screen position. The 
screen data positions have been previously defined within 
the ATP software using a global variable. The cursor is set 
to the desired position by executing the ATP library com- 
mand "Setcursor" which issues the HLLAPI function calls 
to position the cursor on the screen. 

Upon completion of the "Setcursor" function, the key- 
strokes that make up the User ID (entered earlier) are sent to 
the mainframe screen at the desired position using the 
Sendkey library command. This process is repeated for the 
password entered earlier. After both the ID and password 
have been entered, *@ E* is used to execute the CICS 
transaction by hitting enter. 

The virtual presentation space is then checked using the 
ATP library command "Chksign" to verify the sign-on 
process has been successful and that the User ID and 
Password have been accepted at step 84. At this point, 
personal computer 44 has successfully logged on to main- 
frame system 20. A 4 T>oclear" library command is executed 
to clear the presentation space. 

The next function of the system is to send keystrokes to 
initiate a transaction processing application and verify that 
the mainframe main menu is displayed at step 86. The 
keystrokes to initiate the application system transaction on 
the mainframe are executed using the "Sendkey" library 
command. For example, 'MEDA@E* may be executed to 
begin operation of a medical insurance claims transaction 
system for example available from Medicare Claims Pro- 
cessing System of Blue Cross/Blue Shield of Arkansas 
(referred to as "Med A system" below). The following 
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description utilizes screens from the Med A system to assist 
in describing the error correcting function. 

ATP library command, "Chkmain" is then executed which 
issues the HI I APT function calls to search the presentation 
space to look for keywords which identify the current 
screen, as the Med A main menu for example at step 88 (FIG. 
8). 

The cursor is positioned at the field on the virtual screen 
where the clerk number is to be entered using the "Setcur- 
sor" ATP library command. The clerk number is sent to the 
screen using the Sendkey library command. This process is 
repeated for the Med A clerk password field. At this point 
personal computer 44 has logged in to the Med A 
application, for example, or any other standard transactions 
processing application. 

The error resolution subsystem 68 of the present invention 
will be explained in relationship to the flow chart of FIG. 9. 
The cursor is positioned at the selection line for the Paper- 
less Suspense function at step 90 as is common to mainframe 
transaction system on the main menu using the "Setcursor** 
library command. This function is selected by sending 
keystrokes *S@E' or other pre-identified keystrokes to the 
mainframe using the "Sendkey** library command. The 
paperless suspense selection screen is presented and this is 
verified by the ATP library command "Chkselcf which 
executes the HLLAPI functions calls to search the presen- 
tation space and verify the expected screen has been 
received. Other pre-error correction steps dependent upon 
particular mainframe applications may also be conducted at 
this time. 

The cursor is then positioned at the list selection position 
using the Setcursor library command. The keystrokes to 
insert the value of *L* are executed using the Sendkey library 
command. Alternatively, other values may be input to main- 
frame 20 depending on the transaction application running 
thereon. The cursor is positioned at the Error code selection 
position using the "Setcursor" library command. The value 
of the error code is sent using the "Sendkey** library com- 
mand. This value for the error code comes from the pre- 
defined list of error codes the ATP process is capable of 
handling. As a general methodology of operation, the ATP 
program will access all data associated with each error code 
and. when finished, move on to the next error code until all 
error codes have been worked. 

After the error code has been specified, *<§>E* (Enter) is 
issued using the "Sendkey" library command to process the 
selection screen. The claims or more particularly a transac- 
tion list screen is presented and shows the list of claims or 
transactions that have the error specified on the selection 
screen in step 92. This screen is verified by executing the 
ATP library command Chkslist which issues the HLLAPI 
function calls to search the presentation space to verify that 
the Suspense List screen is currently displayed. 

The transactions list for most standard mainframe trans- 
action systems includes screen displays having 10 claims or 
transactions per screen. The ATP process follows the meth- 
odology of accessing each claim on the screen at step 94 and 
then generating keystrokes to page forward (F8) after all 
claims on the current screen have been accessed. This is 
repeated until all claims have been accessed far the current 
error code. The end of die list of claims is recognized by the 
presence of ascii code 32 (spaces) in the screen position 
normally occupied by the claim control number. 

The ATP program now positions the cursor at the select 
line for the first claim on the list screen using the "Setcursor** 
library command. Data from the screen is read by executing 
the ATP library command "Copyit" which issues the 
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HLLAPI function calls to copy a piece of presentation space 
to a string variable. This string variable now contains data 
from die screen position for the "Work Indicator** from the 
claims list screen. This Indicator indicates whether or not the 

5 claim has already been worked. If the Work Indicator shows 
previous activity, the ATP process bypasses this claim, sets 
the cursor position up to the next occurrence of the claim 
select position and continues. 

The claim is selected by sending keystrokes to insert an V 
on the select line followed by *@E* to hit enter. The claim 
is displayed and this is verified by executing the * < Chkclaim" 
library command which issues the HLLAPI function calls to 
search the presentation space and verify that a claim is 
currently displayed. 
Error messages are displayed on the last 4 lines of the 

15 claim screen when the claim is first selected. The ATP 
captures the error codes present on the claim by executing a 
procedure called i4 Gct errors**. This procedure combines the 
ATP library commands of **Setcursor** and "Copyit*' to 
capture and store all the error code information to string 

20 variables. The error codes are analyzed and individual pieces 
of data separated as follows, for example: 
Error field identifier— positions 1-3 
Error line identifier — position 4 
Error Code— positions 5-8 

25 For each error code that the ATP system can process, 
control is transferred to a procedure paragraph that work 
through the specific requirements for the error at step 96. 

For example, an error here, for demonstration purposes, 
may correct prices on a line item charge at 80% of a 

30 submitted charge (Error Code 567 from a typical Med A 
system for example). 

Data for line item charges maybe displayed of the 4th of 
5 screens of claim data, for example. The ATP procedure 
checks to see which page is currently displayed and men if 

35 the page number is not the desired page, steps are initiated 
to move to the correct page. In this case, the function 
Chkpg4 is executed. The claim is normally at page 1 when 
first displayed, so in this case, the ATP procedure uses the 
"Setcursor*' and "Copyit" library commands to read the 

40 current page number. Because the current page is not the 
desired page, the ATP procedure executes Gopg4 which uses 
the library commands "Setcursor**. "Sendkeys**, and 
"Copyit** to initiate the change to page 4. The "Copyit" 
function reads the page ID again after the movement has 

45 occurred to verify the current page indicator. 

The error message info is utilized again and the ATP 
program looks at the Error Line identifier to know which of 
the items is the one in error. The line is identified by a value 
of A-Z. plus @, & $ in the Error Line identifier. 

50 If the index of the item in error is greater than sixteen, or 
not on the screen, commands are issued using the "Setcur- 
sor** and "Sendkeys" library commands to move the display 
to an alternate screen for display which shows the correct 
charge items. In this way. the system 50 may be set up, 

55 dependent upon the mainframe transaction application, to 
traverse through a particular transaction record, find an error, 
and correct that error. 

The field positions of the error line are looked up from the 
internal table of field position declarations created when 

60 adapting the system to a particular transaction application 
and the cursor is positioned on the HCPCS code field of the 
line in error using the "Setcursor** library command. The 
HCPCS code is copies using the "Copyit** library command. 
If the last 4 digits of the HCPCS code are *9999\ for 

65 example in a Med A system, the procedure is to send a 
development letter on the claim or transaction requesting 
additional detail information about the charge or change. 
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This is accomplished by setting a desired letter H> and 
message number and executing a procedure called Develltr 
that accesses the Letter Writer screen from the claim screen 
by sending *@8' (F8). In this way. personal computer 44 
may again acquire additional information if insufficient 
information to fix a particular error is available. Certain data 
inconsistencies may be resolved by obtaining information 
from another data base. For such situations, personal com- 
puter 44 may include a data base or communications hard- 
ware and software which can be used to obtain the needed 
data. 

The presentation space is searched for keywords that 
identify this new screen as the letter generation screen using 
the ATP library command 4i Chkltrgen". 

The cursor is positioned at the letter number field using 
the "Setcursor" library command. 

The desired letter number is inserted on the letter request 
screen using the "Scndkeys" library command. The presen- 
tation space is checked using the ATP library command 
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transactions or claims having the same initial Error code 
selected are now worked on in similar fashion in step 98. 
After all transactions or claims for a particular Error code 
have been worked on. work proceeds to Edit transactions or 
claims having other Error codes at step 100. 

After all transactions for all Error codes have been pro- 
cessed at step 102. the ATP Library Command "Doclear" is 
executed and control passes to the mainframe Log-off pro- 
cedure 70 (FIG. 10) and causes the mainframe screen to 
clear at step 104 and Supply Keystrokes to Log Off of 
Production CICS at step 106. Keystrokes are then supplied 
to log off the mainframe and are sent using the "Logoff" 
library command. The userid is logged off and the main- 
frame banner screen is re-displayed. The presence of the 
mainframe banner screen is verified using the "Chkbanner" 
library command at step 108. 

Upon completion of the main ATP processing, the fol- 
lowing functions are performed as shown in the third branch 
56 of the flowchart of FIG. 4. ATP Application summary 
reporting and ATP shut-down procedures (74. 76) perform 



"Chkltrupd w to validate the letter request has been stored 20 the steps necessary to terminate the ATP process and reset 
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successfully. 

The display moves back to the claim screen by issuing an 
*@3' (F3) keystroke using the "Sendkeys" library command. 
The display of the claim or transaction data is verified again 
using the "Chkclaim" ATP library command. 

When a development letter is sent the claim must be 
updated with an indicator to show additional development 
was required. Two additional pieces of information are 
plugged into the claim record at prescribed positions using 
the "Chkpgx'\ "Setcursor". and "Sendkeys" commands for 
example in a Med A system application. 

If the last four digits of the HCPCS code are not '9999*. 
in this example then the cursor is positioned on the Total 
Charges filed of the error line using the Setcursor library 
command. 

The Total Charge amount is extracted from the screen 
using the "Copyif library command the value is stored to a 
variable. 

The data string that represents the Total Charge is con- 
verted to a numeric value. 80% of the total Charge is 
calculated and stored in a new variable. This new figure will 
be plugged back into the claim screen in the rate field, for 
example to effectively fix the error. 

The cursor is positioned on the line item Rate field using 
the proper field position and the "Setcursor" library com- 
mand. The numeric data (80% of charge) is reformatted as 
a string variable and plugged into the screen using the format 
of the Rate field by the "Sendkeys" command. 

The cursor is then moved to manual price indicator 
position on the line item using the proper field position and so 
the "Setcursor" command. A value of *Y' is plugged into the 
Manual Price indicator field using the "Sendkeys" library 
command. 

A report of the current activity is written to the audit log 
using the "Printif ATP library command. Information writ- 
ten to the log includes the claim control number and a 
message indicating the nature of the processing that has been 
performed. 

Error messages 2-4 or more for this claim or transaction 
are read if a valid value is present and the error can be 60 
worked by the ATP process, the actions are performed. After 
all errors are processed, the claim is stored by issuing an 
•@9* (FS>) or Enter command using the "Sendkeys" library 
command. 

The display returns to the claim list screen. The screen 65 
display is validated by searching the presentation space 
using the '*Chkslisf library command as before. Other 



the operating environment thereby ending execution of the 
ATP process. 

One of the reports created is that of the processing total is 
written to the audit log file and can include the following: 
25 Total records processed, total records bypassed and percent 
of records processed. The report file is closed and saved to 
the personal computer hard drive. 

The system then initiates and executes the ATP library 
command "Discnect" which issues the HLLAPI function 
calls to disconnect the default terminal emulator window 
previously selected. The return code from the "Discnect" 
function is checked. If an unsatisfactory return code is 
found, processing branches to an error handling routine 
which reports key statistics, displays error messages specific 
to this situation and then terminates the processing. 

The ATP system then executes the "Stopclose intercept" 
ATP library command. This issues the HLLAPI function 
calls to turn off the monitor function that prevented the 
mainframe session window from being closed while under 
the control of the ATP procedure and system. 
40 The END statement causes normal termination of the ATP 
program and execution ceases. 

While this invention has been described as having a 
preferred design, the present invention can be further modi- 
fied within the spirit and scope of this disclosure. This 
45 application is therefore intended to cover any variations, 
uses, or adaptations of the invention using its general 
principles. Further, this application is intended to cover such 
departures from the present disclosure as come within 
known or customary practice in the art to which this inven- 
tion pertains and which fall within the limits of the appended 
claims. 

What is claimed is: 

1. A process for automated transaction review by a local 
computer of transaction data records used with a transaction 
55 processing program on a remote computer comprising the 
steps of: 

establishing communication between the remote com- 
puter and the local computer; 
initiating the transaction processing program by the local 

computer; and 
performing error resolution processing by the local com- 
puter emulating a human operator interacting with the 
transaction processing program, the local computer 
using logic prograniming to perform error analysis to 
determine an appropriate interaction with the transac- 
tion processing program, if needed, to resolve each 
error. 
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2. The process of claim 1 wherein said establishing step 
includes the local computer emulating a human operator 
logging on to the mainframe computer. 

3. The process of claim 1, the transaction processing 
program producing transaction data records with associated 
transaction error codes for each data record that cannot be 
processed wherein said performing error resolution step 
includes accessing a list of error transactions related to the 
transaction error codes produced by the transaction process- 
ing program whereby error resolution processing is com- 
pleted without involving any human operator. 

4. The process of claim 3 wherein said accessing step 
includes selecting ones of said error transactions according 
to an error transaction code related to the error transactions. 

5. The process of claim 1 wherein said error resolution 
step includes accessing a data base to resolve inconsistencies 
in a transaction data record. 

6. The process of claim 1 wherein said error resolution 
step includes using a predetermined set of procedural rules 
to evaluate and correct a transaction data record. 

7. The process of claim 1 further including the step of 
logging off the mainframe computer after said error resolu- 
tion processing step. 

8. The process of claim 1 further including the step of 
creating a log file indicating error resolution processing 
which occurred in said error resolution processing step. 

9. The process of claim 1 wherein said error resolution 
step includes generating and sending keystroke sequences to 
the mainframe computer to alter an element of a transaction 
data record. 

10. An apparatus for automated transaction review of 
transaction data records used with a transaction processing 
program on a remote computer, said apparatus comprising: 

communication means for communicating with the 

remote computer; 
means for initiating the transaction processing program on 

the remote computer via said communication means. 

and 

error resolution means for emulating a human operator 
interacting with the transaction processing program to 
correct errors in the transaction data records, said error 
resolution means including logic means for performing 
error analysis to determine an appropriate interaction 
with the transaction processing program, if needed, to 
resolve each error, whereby error resolution processing 
is completed without involving any human operator. 

11. The apparatus of claim 10 wherein said communica- 
tion means includes means for emulating a human operator 
logging on to the mainframe computer. 

12. The apparatus of claim 10, the remote computer 
transaction processing program producing transaction data 
records with associated transaction error codes for each data 
record that cannot be processed wherein said error resolution 
means includes means for accessing a list of error transac- 
tions related to the transaction error codes produced by the 
transaction processing program, 

13. The apparatus of claim 12 wherein said accessing 
means includes means for selecting ones of said error 
transactions according to an error transaction code. 

14. The apparatus of claim 10 wherein said error resolu- 
tion means includes means for accessing a data base to 
resolve inconsistencies in a transaction data record. 

15. The apparatus of claim 10 wherein said error resolu- 
tion means includes a predetermined set of procedural rules 
used to evaluate and correct a transaction data record. 

16. The apparatus of claim 10 further including means for 
logging off the mainframe computer. 
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17. The apparatus of claim 10 further including means for . 
creating a log file indicating error resolution accomplished 
by said error resolution means. 

18. The apparatus of claim 10 wherein said error resolu- 
5 tion means includes means for generating and sending 

keystroke sequences to the mainframe computer to alter an 
element of a transaction data record. 

19. In a personal computer system having means for 
operating on a predetermined mainframe computer database 

io containing transaction error codes and data and a set of 
relationships among the transaction error codes and data, a 
method for processing transactions on the mainframe com- 
puter comprising the steps of: 

logging on the mainframe computer; 
15 reading a transaction from the mainframe; 

the personal computer system performing analysis func- 
tions on a transaction on the mainframe processing 
system, the personal computer system using logic pro- 
gramming to perform error analysis to determine an 
20 appropriate interaction with the transaction processing 
program, if needed, to resolve each error; 
performing update processing on the transaction data in 
accordance with the determined interaction of the logic 
programming, on the mainframe processing system; 
25 and 

logging off the mainframe computer. 

20. Acomputer system including a central processing unit 
and associated memory for emulating the actions a human 

M being performs while working at a mainframe computer 
terminal to perform analysis functions on a mainframe 
transaction processing system, comprising: 

means for initiating a mainframe application of the trans- 
action processing system; 
33 means for accessing transaction data elements from the 
mainframe transaction processing system; 
means for analyzing the transaction data elements using a 
preselected set of procedures, said analyzing means 
including logic means for performing error analysis to 
40 determine an appropriate interaction with the transac- 
tion processing program, if needed, to resolve each 
error, and 

means for performing update functions on the transaction 
data element on the mainframe transaction processing 
45 system in accordance with the interaction determined 
by said logic means. 

21. The computer system of claim 20 further including 
means for logging on the mainframe computer and means 
for logging off the mainframe computer. 

50 22. The computer system of claim 20 wherein said means 
accessing transaction data elements include searching said 
transaction data elements that contain a preselected error 
code. 

23. The computer system of claim 20 in which said means 
55 for performing update functions are keystroke sequences 

generated by the computer system and sent to the mainframe 
computer to alter specific mainframe transaction data ele- 
ments. 

24. The computer system of claim 20 in which if insuf- 
60 ficient data is available to correct said transaction data 

elements, a request far more information is created. 

25. A computer system including a central processing unit 
and associated memory for emulating the actions a human 
being performs while working at a mainframe computer 

65 terminal to perform analysis functions on a mainframe 
insurance claim transaction processing system, the insurance 
claim transaction processing system including a transaction 
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processing program producing insurance claim transaction means for performing update functions on the mainframe 
data records with associated transaction error codes for each required by said set of procedures related to said 
data record that cannot be processed said computer system matched error code and said insurance claim transac- 
comprising: tion data record whereby update functions are corn- 
means for initiating the transaction processing program; 5 pleted without involving any human operator, 
means for accessing data elements from insurance claim 26. The computer system of claim 25 further including 
transaction data records stored on the mainframe sys- means for logging on the mainframe computer and means 
tem; for logging off the mainframe computer, 
a predetermined database stored in the associated 27. The computer system of claim 25 in which said means 
memory, said database containing transaction error to performing update functions are keystroke sequences 
codes and set of procedures related to each transaction generated by the computer system and sent to the mainframe 
error code for correcting data elements from said computer to alter specific mainframe insurance claim trans- 
insurance claim transaction data records having a action records. 

matching error code; 15 28. The computer system of claim 25 in which if insuf- 

means for comparing said data elements to transaction ficient data is available to correct said insurance claim 

error codes stored within said database to find a match- transaction record, a request for more information is created, 
ing error code and insurance claim transaction data 

record; and ***** 
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